Dynamic Policy Server Allocation

ABSTRACT

A policy control architecture and method for dynamically allocating policy servers to mobile devices is described herein. The policy control architecture introduces a new policy control element called the policy server control function. The policy server control function dynamically allocates policy servers to mobile subscribers when the mobile subscribers attach to an access network. In some embodiments, the policy server control function may also deallocate policy servers when mobile subscribers detach from all access networks to make the policy server resources available for other mobile devices.

TECHNICAL FIELD

The present invention relates generally to policy control forcommunication networks and more particularly to a policy controlarchitecture and method for dynamically allocating policy servers.

BACKGROUND

Policy control is a process for controlling the use of network resourcesaccording to a predefined policy. The policy typically comprises aformal set of rules that govern how network resources may be used. Whena mobile device attempts to access a network or invoke a service, thepolicy control function determines whether the access or service isallowed based on the policy established by the service provider. Policyrules may be enforced through admission control and/or quality ofservice (QoS) control.

In IP Multimedia Subsystem (IMS) networks, the policy control functionis implemented by two functional entities: The policy enforcement pointand the policy decision point. the policy enforcement point typicallyresides in a node through which user traffic flows. The policyenforcement point blocks or permits user traffic based on the applicablepolicies. The policy decision point is a policy server that determineswhat policy rules apply to a given service. A network typicallycomprises a plurality of policy decision points or policy servers thatare allocated to serve particular mobile devices.

The demands for capacity in policy servers in emerging networks arelikely to grow for several reasons. The current static nature ofpolicies means that the policy decision point, or policy server, istypically involved only during service and bearer establishment. Whenmore advanced and dynamic policies are introduced, the policy serverswill have to continuously collect dynamic input data for making policydecisions. Additionally, the growing number of subscribers and theadoption rate of packet data services indicate that the load on policyservers will increase.

Given the increasing demands on policy servers, an efficient, flexible,and easily-scalable policy control architecture is needed to meet theincreased demand on policy server resources.

SUMMARY OF THE INVENTION

The present invention provides a policy control architecture and methodfor dynamically allocating policy servers to mobile devices or mobilesubscribers. The policy control architecture introduces a new policycontrol element called the policy server control function. The policyserver control function dynamically allocates policy servers to mobilesubscribers when the mobile subscribers attach to an access network. Insome embodiments, the policy server control function may also deallocatepolicy servers when mobile subscribers detach from all access networksto make the policy server resources available for other mobile devices.The policy server control function receives attach/detach eventnotifications from a home subscriber server or other network elementwith an overview of multiple access networks. In response to attachevent notifications, the policy server control function allocates apolicy server from a pool of policy servers to a mobile subscriber. Insome embodiments, the policy server control function may also receivedetach event notifications and deallocate the policy servers when amobile subscriber is no longer attached to any access network. Thepolicy server control function also provides address information forallocated policy servers to other requesting entities, such as policyenforcement points and other policy server control functions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary policy control architecture for acommunication network.

FIG. 2 illustrates exemplary policy control procedures using a statelesspolicy server control function according to a first embodiment.

FIG. 3 illustrates exemplary policy control procedures using a statelesspolicy server control function according to a second embodiment.

FIG. 4 illustrates exemplary policy control procedures using a statefulpolicy server control function.

DETAILED DESCRIPTION

FIG. 1 illustrates exemplary functional entities of a communicationnetwork 10 for implementing policy control. Policy control is amechanism for implementing a set of policy rules that govern how networkresources are used. When a mobile device 100 attempts to access networkresources or to invoke certain services, the policy control functiondetermines whether the access or service is allowed based on a set ofpolicy rules. The policy rules may be session specific or sessionnon-specific, and pre-defined or dynamic. The policy control functionmonitors the traffic in the user plane to ensure that the policy rulesare not violated. As one example, the policy rules may specify the typesof codecs or media bearers that are allowed for a particular dataservice flow. The policy control architecture illustrated in FIG. 1 maybe used, for example, to implement policy control in IMS networks orother IP networks.

The main components of the network 10 comprise an access network (AN)12, home subscriber server (HSS) 14, policy enforcement point (PEP) 16,policy server (PS) 18, policy server control function (PSCF) 20, andapplication function (AF) 22. Those skilled in the art will appreciatethat the functional entities such as the HSS 14, PEP 16, PS 18, PSCF 20,and AF 22 may be implemented in a computer with suitable processing andmemory resources.

The AN 12 provides mobile devices 100 with access to the communicationnetwork 10. The AN 12 may, for example, comprise cellular networks suchas Universal Mobile Telecommunications System (UMTS), Wideband CodeDivision Multiple Access (WCDMA), Global System for MobileCommunications (GSM), or Code Division Multiple Access (CDMA) networksproviding wireless mobile communication services to mobile telephonesand other mobile devices. The AN 12 could also comprise a wireless localarea network (WLAN) such as a Wireless Fidelity (WiFi) or WorldwideInteroperability for Microwave Access (WiMax) network. The presentinvention should also work with future access technologies.

The HSS 14 is the central repository for subscriber information. The HSScomprises a processor 14A and memory 14B for performing the functionsherein described. The HSS 14 stores subscriber data required forhandling multimedia sessions in memory 14B. This data includesinformation such as the subscriber name and ID, location, user profilesincluding subscriber services and QoS requirements, and othersubscriber-related information. The HSS 14 is notified when a subscriberattaches to or detaches from the access network 12 and stores thisinformation in a subscriber database in memory 14B. A single HSS 14 mayserve multiple ANs 12 using different radio access technologies. Thus,the HSS 14 may, in some embodiments, have knowledge of the subscriberstatus in multiple ANs 12. As will be described hereinafter, the HSS 14may also store the addresses of PSs 18 assigned to subscribers. The HSS14 may include a Subscription Profile Repository as described in 3GPPstandards. The Lightweight Directory Access Protocol (LDAP) may be usedfor communication with other network entities, such as the PSCFs 20, PSs18, and PEPs 16.

The PEP 16 is a policy control element responsible for enforcing policyrules in the user plane. PEP 16 comprises a processor 16A and memory 16Bfor performing the functions herein described. While shown as a separatenetwork element in FIG. 1, the PEP 16 is typically located in a gatewayconnecting AN 12 to an IMS network or other IP network. In a GSM or UMTSnetwork, the PEP 16 may be located at the GGSN. For a WLAN interworkingwith a UMTS network, the PEP 16 may be located at the PDG. PEP 16receives access requests and service requests from mobile devices 100.The PEP 16 evaluates whether the requested access or services areallowed based on the applicable policy rules. In response to an accessor service request, the PEP 16 may request a policy decision from a PS18. A policy decision comprises a set of policy rules to be applied bythe PEP 16 to the access or service request. The PEP 16 may grant accessto network resources or deny access or service requests according to thepolicy rules. The PEP 16 may, for example, comprise a policy andcharging rules enforcement function (PCEF) as described in 3GPP TS23.203 V. 7.4.0 (September 2007).

The PS 18 is a policy control element responsible for determining thepolicy rules applicable to a service data flow. The PS 18 functions as apolicy decision point (PDP). PS 18 comprises a processor 18A and memory18B for performing the functions herein described. The PS 18 collectsinformation from a variety of sources for determining relevant policyrules and decides how a certain service data flow shall be treated. PS18 receives policy requests from PEPs 16 and other entities and makespolicy decisions. The network 10 may comprise a plurality of PSs 18which may be dynamically allocated as hereinafter described. The PS 18and PEP 16 may communicate using known protocols such as RMI, COPS,Radius, Diameter, etc. The PS 18 may, for example, comprise a policy andcharging rules function (PCRF) as described in 3GPP TS 23.203 V. 7.4.0(September 2007).

The PSCF 20 is a policy server control function that dynamicallyallocates PSs 18 to mobile devices 100 or mobile subscribers when themobile devices 100 attach to an access network 12. For simplicity,reference to the allocation of PSs 18 to mobile devices 100 in thespecification and claims should be understood to include allocation ofPSs 18 to subscribers of network-based communication services who use amobile device 100 to access network services and resources. The PSCF 20comprises a processor 20A and memory 20B for performing the functionsherein described. In some embodiments, the PSCF 20 may also de-allocatethe PSs 18 when the mobile device 100 detaches from the AN 12 to makethe policy server resources available for other mobile devices 100. ThePSCF 20 is also responsible for providing the addresses of PSs 18 toother policy control elements. For example, the PSCF 20 may provideaddress information for PSs 18 to PEPs 16, the HSS 14, and/or otherPSCFs 20. When the mobile device 100 is roaming, the PSCF 20 may provideaddress information for home PSs 18 to PEPs 16 and/or PSCFs 20 in thevisited network. The PSCF 20 has no corresponding element in 3GPP TS23.203 V. 7.4.0 (September 2007).

The AF 22 is an entity offering application or services that requiredynamic policy control over user plane behavior. AF 22 communicates withthe PS 18 to transfer session information, which may be used forselecting the appropriate policy rules. One example of an applicationfunction is the P-CSCF in an IMS system. The AF 22 is described in 3GPPTS 23.203 V. 7.4.0 (September 2007).

The exemplary embodiments of the invention provide a mechanism fordynamic allocation of PSs 18 from a pool of PSs 18 in a way that allowsefficient, flexible, and easily scalable management of policy serverresources. The PSCF 20 uses events that correspond to a mobile device'sattachment/detachment from an AN 12 as triggers to allocate/deallocatePSs 18. The attach/detach event triggers are preferably channeledthrough an entity, such as the HSS 14, that has an overview of themobile device's attach/detach status in multiple ANs 12, which mayimplement different access technologies. The HSS 14 notifies a PSCF 20of attach events and of detach events in some embodiments. The PSCF 20allocates a PS 18 to the mobile device 100 responsive to the attachevent and may direct policy requests from other policy control entities(e.g., PEPs 16) to the allocated PSs 18. There are two basic variants ofthe PSCFs 20: stateless and stateful. The stateless PSCF 20 may be keptsimple; however, the stateful PSCF 20 is better adapted to handlerequests form other policy control entities.

FIG. 2 illustrates operation of an exemplary stateless PSCF 20 accordingto one embodiment. The HSS 14 detects an attach event when a mobiledevice 100 attaches to an AN 12 (step a). In order to receive attachevent notifications from the HSS 14, the PSCF 20 may subscribe to attachevents from the HSS 14. For example, the PSCF 20 may subscribe to attachevents using SIP or diameter protocols.

In response to the attach event, the HSS 14 sends an attach eventnotification to the PSCF 20 (step b). The attach event notificationincludes a mobile device identifier associated with the mobile device100. The PSCF 20 allocates a PS 18 to implement the policy controlfunction for the mobile device 100 and sends an allocation notificationto the selected PS 18 (step c). The assignment notification includes theidentity of the mobile device 100 to which the PS 18 has been allocated.The PS 18 stores this information in its memory 18B, retrieves therelevant profiles and policies, and may start to collect input data. ThePSCF 20 also sends an allocation notification to the HSS 14 as aresponse to the attach event notification (step d). The allocationnotification includes the address of the PS 18 that is allocated to themobile device 100. The HSS 14 stores an association between the mobiledevice identifier and the PS address in its subscriber database to usefor directing future policy requests to the allocated PS 18.

When a requesting node needs a policy decision from the PS 18, it sendsthe policy request to the PSCF 20 (step e). The requesting node may, forexample, comprise a PEP 16 or a PSCF 20 in a remote network. The policyrequest includes an identifier for the mobile device 100 for which apolicy decision is needed. The PSCF 20 may act as either a relay serveror a redirect server. In either case, upon receipt of the request, thePSCF 20 queries the HSS 14 for the address of the PS 18 allocated to themobile device 100 (step f). As previously noted, the HSS 14 stores anassociation between the mobile device identifier and the allocated PS18. The HSS 14 looks up the PS 18 allocated to the mobile device 100specified in the query and returns the PS address to the PSCF 20 as aresponse to the query (step g). When the PSCF 20 acts as a relay server,it forwards the policy request to the allocated PS 18 (step h1) andrelays the subsequent reply from the PS 18 to the requesting node (stepsi1 and j1). When the PSCF 20 acts as a redirect server, the PSCF 20sends a redirect message to the requesting node, including the addressof the allocated PS 18 (step h2). The requesting node may then contactthe PS 18 directly. The requesting node resends the policy request tothe PS 18 (step i2), to which the PS 18 responds with its policydecision (step j2).

The PS 18 may also be deallocated when the mobile device 100 detachesfrom all ANs 12. When the HSS 14 detects detach events (step k), itdetermines whether the mobile device 100 is currently attached to any AN12. If so, the detach event may be ignored. If the mobile device 100 isno longer attached to any AN 12, the HSS 14 determines the allocated PS18 and sends a detach event notification to the PS 18 to deallocate thePS 18 (step I). The deallocation frees the policy server resources to beused for other mobile devices 100. In some embodiments, the PS 18 maysend a deallocation notice to the PSCF 20 when it has been deallocated(step m). The allocated PSs 18 may have implicit subscriptions toreceive detach events notification from the HSS 14.

In some embodiments, the HSS 14 may be responsible for notifying PS 18when the PS 18 is allocated to a mobile device 100 as shown in FIG. 3.In this case, the HSS 14 notifies the PSCF 20 (step b) when an attachevent occurs (step a). The PSCF 20 allocates a PS 18 to the mobiledevice 100 as previously described. However, the PSCF 20 does not sendan allocation message to the PS 18. Instead, the PSCF 20 sends anallocation message to the HSS 14 including the address of the allocatedPS 18 (step c). The HSS 14 in turn may send an allocation message to theallocated PS 18 to notify the PS 18 that it has been allocated to aparticular mobile device 100 (step d). Steps e-m are the same aspreviously described.

In the embodiments shown in FIGS. 2 & 3, the requesting node mayalternatively query the HSS 14 directly for the address of an allocatedPS 18, rather than send the policy request to the PSCF 20. For example,assume that the requesting node comprises a Serving Call Session ControlFunction (S-CSCF) in an IP Multimedia Subsystem (IMS) network. When themobile device 100 registers with the S-CSCF for IMS services, the S-CSCFmay query the HSS 14 for the address of the PS 18 and then contact thePS 18 directly without going through the PSCF 20.

The stateless PSCF 20 allows the PSCF 20 to be very simple with only afew limited functions. However, this approach allows only relativelysimple allocation algorithms for allocating PSs 18. For example, thePSCF 20 could allocate PSs 18 according to a simple round-robin scheme.According to one embodiment, a load balancing allocation scheme may beimplemented through a slight compromise in statefulness. To enable aload balancing allocation scheme, the PSCF 20 could maintain a separatecounter in its memory 18B for each PS 18 reflecting the number of mobiledevices 100 currently served by each PS 18. The allocation counter for aPS 18 would be increased each time PS 18 is allocated to a new mobiledevice 100, and decremented each time the PS 18 is deallocated. Sincethe stateless PSCF 20 is not involved in deallocation, the PSs 18 wouldhave to inform the PSCF 20 when the PS 18 is deallocated (step m in FIG.2). A PSCF 20 implementing this kind of load-based allocation schemewould thus maintain a PS state (count) for each PS 18, but would not berequired to maintain subscriber state for each subscriber. Therefore,the PSCF 20 could still be regarded as more or less a stateless PSCF 20.

FIG. 4 illustrates the operation of a stateful PSCF 20 according toanother exemplary embodiment. The stateful PSCF 20 allocates PSs 18 tomobile devices 100 in a manner similar to that previously described.Additionally, the stateful PSCF 20 is involved in deallocation of PSs18. The stateful PSCF 20 may subscribe to attach/detach eventnotifications from the HSS 14. In this embodiment, the PSs 18 do notneed to subscribe to detach events from the HSS 14. When the HSS 14detects an attach event (step a), the HSS 14 sends an attach eventnotification to the PSCF 20 in accordance to the subscription for attachevents (step b). The PSCF 20 allocates a PS 18, stores the allocation inits internal records, and sends an allocation notification to the PS 18(step c). When the PS 18 is allocated to a mobile device 100, itretrieves the relevant profiles and policies and may start to collectinput data. The PSCF 20 may optionally inform the HSS 14 of theallocation.

When a requesting node, such as a PEP 16 or AF 22, needs to contact thePS 18 for a mobile device 100, the requesting node sends a policyrequest to the PSCF 20 (step d). The policy request includes anidentifier associated with the user or mobile device 100. The PSCF 20may act as either a relay server or redirect server. In either case, thePSCF 20 consults its internal records to determine the address of the PS18 allocated to the mobile device 100.

When the PSCF 20 acts as a relay server, it forwards the policy requestto the allocated PS 18 (step e1) and relays the subsequent reply fromthe PS 18 to the requesting node (steps f1 and g1). When the PSCF 20acts as a redirect server, the PSCF 20 sends a redirect message to therequesting node, including the address of the allocated PS 18 (step e2).The requesting node may then contact the PS 18 directly. The requestingnode resends the policy request to the PS 18 (step f2), to which the PS18 responds with its policy decision (step g2). The requesting node maystore the address of the PS 18 for future use.

When the HSS 14 detects that the mobile device 100 is no longer attachedto any AN 12 (step h), it sends a detach event notification includingthe mobile device identifier to the PSCF 20 (step i). The PSCF 20deallocates the PS 18 and sends a deallocation notification to theconcerned PS 18 (step j).

If SIP is used for interaction between the involved nodes, the statefulPSCF 20 may be seen as a back-to-back user agent, or a combinedback-to-back user agent and redirect server. During policy serverallocation, the PSCF 20 acts as a back-to-back user agent. When handlingpolicy requests, it acts as either a back-to-back user agent in therelay case, or as a redirect server in the redirection case.

Because the stateful PSCF 20 is responsible for allocation anddeallocation of PSs 18, it may keep track of the number of mobiledevices 100 allocated to each PS 18 and may implement load balancingschemes as previously described.

In the Third Generation Partnership Project System ArchitectureEvolution (3GPP SAE) architecture, policy server allocation in a visitednetwork may be performed in essentially the same manner as describedabove. The HSS 14 in the visited network is involved as a proxyAuthentication Authorization Accounting (AAA) server for userauthentication when the mobile device 100 attaches to the visitednetwork. At this point, the HSS 14 in the visited network may trigger apolicy server allocation to the visiting mobile device 100 by sending anattach event notification to the PSCF 20 in the visited network. The HSS14 in the home network may also trigger a policy server allocation inthe home network when notified that the subscriber is attached to thevisited network. The attach event notification to the PSCF 20 in thehome network may indicate that the mobile device 100 is roaming in avisited network and that there is a PS 18 allocated to the mobile device100 in the visited network. The allocation notification sent to the PS18 may also inform the PS 18 that the subscriber is roaming and there isa PS 18 allocated to the mobile device 100 in the visited network. ThePS 18 in the home network may use this information to retrieve relevantpolicies from the PS 18 in the visited network responsive to a policyrequest. Similarly, the PS 18 in the visited network knows from themobile device identity that the subscriber is a roaming and thattherefore there is a PS 18 allocated to the mobile device 100 in thesubscriber's home network. The PS 18 in the visited network may retrievepolicy information from the PS 18 in the home network.

A PS 18 in the home network or in the visited network may locate a PS 18in another network through the PSCF 20 in the remote network. The PSCF20 in the remote network may be located, for example, through a DNSservice request. A DNS service request is a DNS request for an IPaddress or FQDN of an entity that supports a particular service. The DNSrequest typically contains the FQDN of the concerned domain (i.e., thehome or visited network domain in this context) prepended by a prefixindicating the particular service concerned. Alternatively, the HSSs 14in the different networks may exchange addresses of the PSCFs 20, aswell as other information such as port numbers and supported transportprotocols, through Diameter during mobile device authenticationprocedures. This information may be passed to the allocated PS 18 duringthe PS 18 allocation procedure. This information exchange is preferablybi-directional, so that the HSS 14 and the allocated PS 18 in thevisited network are informed of the address (and possibly otherinformation) of the PS 18 allocated in the home network and the HSS 14and the allocated PS 18 in the home network are informed of the address(and possibly other information) of the PS 18 allocated in the visitednetwork.

In the embodiments described above, a home subscriber server functionsas the source for allocation and deallocation triggers. In someembodiments, gateways may be used in place of the home subscriber serverto generate allocation/deallocation triggers. One possible disadvantageof this approach is that there may be many gateways and that thegateways do not have a complete overview of the user's attachmentstatus. One solution is to assign a centralized entity to maintain theoverall status for the user based on information received from thegateways. For example, the overall status of users could be maintainedby the PSCF 20. Each of the gateways could report changes in the user'sstatus to the PSCF 20, which maintains the overall status for the user.

In one exemplary embodiment, the gateways may report that the user is“attached” if the user has established a session with the gateway, andreport that the user is detached when the session is terminated. ThePSCF 20 may maintain a state for each gateway. The user's overall statuswould be “attached” if the user is attached to at least one gateway, and“detached” if the user is not attached to any gateway. The allocationand deallocation of policy servers 18 for a given user may then betriggered by changes in the overall status of the user as maintained bythe PSCF 20.

If a single gateway is the sole gateway for all traffic from a user, thegateway may provide triggers for the allocation/deallocation of policyserver resources. As one example, a gateway/home agent (GW/HA) in an SAEnetwork may be the source of triggers for allocation/deallocation ofpolicy server resources. A PS 18 may be allocated to a subscriber whenthe subscriber's mobile device registers its first binding in the SAEGW/HA. As long as the mobile device has a binding registered in the SAEGW/HA, or is attached to his home network, the PS 18 remains allocated.When the mobile device is attached to his home network, it may not havea binding registered in the SAE GW/HA, but the SAE GW/HA will still beaware of the mobile device's presence since it is involved in thesignaling triggered by the mobile device's network attachment. Also, itmay receive a request from the mobile device to deregister a previouscare-of address while the mobile device is attached to its home network.

An alternative to using registered bindings and home network presence ascriteria for keeping a PS 18 allocated could be to use securityassociations (SAs) that protect the signaling between the mobile deviceand the SAE GW/HA. The policy server allocation could then be triggeredwhen the SAs are established between the SAE GW/HA and a given mobiledevice, and would remain allocated as long as the SAE GW/HA has at leastone valid SA for the mobile device.

The present invention may, of course, be carried out in other ways thanthose specifically set forth herein without departing from essentialcharacteristics of the invention. The present embodiments are to beconsidered in all respects as illustrative and not restrictive, and allchanges coming within the meaning and equivalency range of the appendedclaims are intended to be embraced therein.

1-48. (canceled)
 49. A method of dynamically allocating a policy serverto a mobile device, said method comprising: receiving from a homesubscriber server an attach event notification when a mobile deviceattaches to an access network; and dynamically allocating a policyserver from a pool of policy servers to said mobile device responsive tosaid attach event notification.
 50. The method according to claim 49,further comprising subscribing to receive said attach eventnotifications from said home subscriber server.
 51. The method accordingto claim 49, further comprising sending an allocation notification tosaid allocated policy server including a mobile device identifieridentifying the mobile device to which the policy server is allocated.52. The method according to claim 49, further comprising receiving apolicy request from a requesting node, said policy request including amobile device identifier.
 53. The method according to claim 52, furthercomprising sending a redirect message to the requesting node includingan address of the policy server allocated to said mobile deviceidentified by said policy request.
 54. The method according to claim 52,further comprising: relaying said policy request to the policy serverallocated to said mobile device identified by said request; receiving apolicy response from said selected policy server; and forwarding saidpolicy response to said requesting node.
 55. The method according toclaim 49, further comprising: maintaining a count for each policy serverin said pool reflecting a current load on each policy server; andallocating policy servers to mobile devices based on the current loadson said policy servers.
 56. The method according to claim 55, furthercomprising receiving a deallocation notification from one of said policyservers indicating that said policy server has been dynamicallydeallocated, and updating said count for the deallocated policy server.57. The method according to claim 49, wherein the attach eventnotification is received from a home subscriber server and furthercomprising sending an address of the allocated policy server to the homesubscriber server.
 58. The method according to claim 49, furthercomprising storing said address of the allocated policy server and amobile device identifier for said mobile device in a policy serverdatabase.
 59. A policy server controller for dynamically allocatingpolicy servers to mobile devices, said policy server controller having aprocessor and a memory whereby the policy server controller isconfigured to: receive an attach event notification when a mobile deviceattaches to an access network; and dynamically allocate a policy serverfrom a pool of policy servers to said mobile device responsive to saidattach event notification.
 60. The policy server controller according toclaim 59, wherein the policy server controller is configured to receivesaid attach event notifications from a home subscriber server.
 61. Thepolicy server controller according to claim 60, wherein the policyserver controller is further configured to subscribe to receive saidattach event notifications from said home subscriber server.
 62. Thepolicy server controller according claim 59, wherein the policy servercontroller is further configured to send an allocation notification tosaid policy server including a mobile device identifier identifying themobile device to which the policy server is allocated.
 63. The policyserver controller according claim 59, wherein the policy servercontroller is further configured to receive a policy request from arequesting node, said policy request including a mobile deviceidentifier.
 64. The policy server controller according to claim 63,wherein the policy server controller is further configured to send aredirect message to the requesting node including an address of thepolicy server allocated to said mobile device identified by said policyrequest.
 65. The policy server controller according to claim 63, whereinthe policy server controller is further configured to: relay said policyrequest to said policy server allocated to said mobile device identifiedby said request; receive a policy response from said selected policyserver; and forward said policy response to said requesting node. 66.The policy server controller according to claim 59, wherein the policyserver controller is further configured to: maintain a count for eachpolicy server reflecting a current load on each policy server; andallocate policy servers to mobile devices based on the current loads onsaid policy servers.
 67. The policy server controller according to claim66, wherein the policy server controller is further configured toreceive a deallocation notification from one of said policy serversindicating that said policy server has been dynamically deallocated, andupdating the count for the deallocated policy server.
 68. The policyserver controller according to claim 59, wherein the policy servercontroller is further configured to send an address of the allocatedpolicy server to the home subscriber server.
 69. The policy servercontroller according to claim 59, wherein the policy server controlleris further configured to store said address of the allocated policyserver and a mobile device identifier for said mobile device in memory.